Subject: Re: Nagi Swaminathan 3/7 comments on flow control

From: Nagi Swaminathan <[email-masked]>
Date: Fri, 11 Mar 94 9:12:53 EST

Peter,

I have tried to answer some of your queries. Hope it is helpful. 

>Nagi,
>I read your suggestion about a receiver-controlled max window size
>carefully because I think we need some creative brainstorming on this
>"lack of feedback" problem.  I could not fully understand what you
>proposed, however.  Could you give an example with some specific
>counter values, and show just what variables are needed where?
>
>My particular points of confusion were:
>  Your max window size seems exactly the same as the NWS variable      
>  in my proposal.  Is that correct?  

   Yes. 

>  It sounds like you are saying     
>  that the sender maintains its own "real" window below this value.    

   Yes.        

>  Is it the start of the "real" window that triggers PREQ?  If so,
>  do we have a problem where the receiver consistently believes it
>  is granting a window value larger than what the sender is using,
>  and over time the difference between the two values keeps growing?

   Yes, that is exactly correct. This is the only difference between
   your proposal and the change I am proposing. 

   I do not see any problem in sender using a smaller window than what
   receiver has allowed as long as he does not exceed the value set
   by the receiver.
 
   This way we will never send more frames than what is necessary. The
   window size will automatically adjust to the network turn-around
   delay. This will utilize the buffer resources  in the receiver
   more efficiently. 

   The receiver has control over the maximum window size and also window 
   size allowed at any point  in time. This I think we want maintain as the 
   receiver is the one  who is aware of the receive buffer availability. 

   It seems we think the receiver by knowing the current window size the
   sender is using can make better use of buffers. If that is the case, 
   the receiver can always infer the current window size being used, from
   the frequency in which the pacing requests are received on a circuit. 

   This will result in the senders who need a larger window, increasing
   the window to what is required subject to the receiver allowing  them to
   do so and the senders who do not need larger window do not increase
   their window beyond what is necessary thereby avoiding sending too many
   packets into the TCP connection and creating congestion which could
   have been avoided. 

>
>Offhand I don't think your ideas pose a patent issue, but as you can
>see I don't really understand them yet. 

>
>As for what we could loosely call the "deadlock issue", you're right
>that this keeps popping up.  I can think of buffering implementations
>that make this a real concern and others that lessen the risks.  We
>are exposed somewhat without an "out of band" pacing mechanism but
>so far no one has shown we're broken in a general enough way to cause
>a move to an "IPMs only on a separate TCP connection" rule.  If anyone
>would like to make the case for this rule, now's certainly the time.
>

I was reading about something called urgent data in TCP which could be
used send the IPMs. But, I do not know whether it is a standard feature 
in all implementations of  TCP. I do not know much about this. But, I am
curious as to what the TCP wizards think about this.

>Peter

regards..

Nagi.

---

From: [email-masked] (Susie Kim Riley)
Date: Mon, 14 Mar 94 10:18:23 EST

>>curious as to what the TCP wizards think about this.

You are right in thinking that not all implementations support
urgent data.  Urgent data is just a matter of processing segments with
the URG bit set in the TCP header quickly.  However, if you have a
problem with congestion and frames are not getting through the TCP
pipe, I don't think that URG would help you.  URG would help you if
wanted the other end to react quickly.  

Maybe you could also have some guaranteed bandwidth for IPMs.  For
example, do not send the maximum amount - always make sure that you
have some room left for IPMs.  You could do this in conjunction with
URG.  I don't think it's unreasonable to say that if you want to
implement this pacing scheme, your tcp implementation should support
URG.  Also, if you didn't have URG, you should still be able to
handle the segment - just not give it the special treatment.

SKR